热门标签 | HotTags
当前位置:  开发笔记 > 后端 > 正文

加工|年货_漫画趣解Flink实时数仓

篇首语:本文由编程笔记#小编为大家整理,主要介绍了漫画趣解Flink实时数仓相关的知识,希望对你有一定的参考价值。我是F

篇首语:本文由编程笔记#小编为大家整理,主要介绍了漫画趣解Flink实时数仓相关的知识,希望对你有一定的参考价值。




我是Flink,最近我抑郁了~


1 搬橡果的小故事

马上过冬了,我和小伙伴灰灰开始屯年货。

今年劳动了大半年,我们收获了整整一车的橡果。众所周知,我们小松鼠们都喜欢把这些心爱的橡果放到储藏室。

于是今天起了个大早,开始搬运这些橡果。

不一会,灰灰突然对我说想要吃一颗昨天摘的灰色小橡果。

我望了望眼前堆积如山的年货,苦恼的摸了摸脑袋:等我搬到了那颗再给你。

灰灰很不开心,嘴里嘟囔着:为啥昨天不能一摘下来我们就搬呢?

我解释道: 我们每年都是攒够一车才一起搬的呀?

看着一边气鼓鼓的灰灰,我放缓了搬运的速度~

抬头望着高高的橡果堆叹了口气。一边搬运,一边翻找他要的那颗小橡果。。。

今天怕是搬不完了~


2 慢 OR 快?

总结下,在故事中我们遇到了几个小烦恼:



  • 每次都是攒了整车橡果才开始搬运,无法及时拿到想要的灰色小橡果

  • 就算我实时搬运。之后再要其他小橡果,我还是不能快速找到,完全记不住之前拿过哪些?放到了哪里?

借由这个小故事,回归到本文主题。

这些关键词也是企业实时数仓建设中常遇到的一些难点和诉求。


2.1 企业实时数仓建设诉求

大多数企业面临数据源多、结构复杂的问题,为了更好的管理数据和赋能价值,常常会在集团、部门内进行数仓建设。

其中一般初期的数仓开发流程大致如下:



  • 获取数据源,进行数据清洗、扩维、加工,最终输出业务指标

  • 根据不同业务,重复进行上述流程开发,即烟囱式开发。

可想而知,随着业务需求的不断增多,这种烟囱式的开发模式会暴露很多问题:



  • 代码耦合度高

  • 重复开发

  • 资源成本高

  • 监控难

为此大量企业的数据团队开始着手数仓规划,对数据进行分层。

数据规整为层级存储,每层独立加工。整体遵循由下向上建设思想,最大化数据赋能。



  • 数据源: 分为日志数据业务数据两大类,包括结构化和非结构化数据。

  • 数仓类型:根据及时性分为离线数仓和实时数仓

  • 技术栈:

    • 采集(Sqoop、Flume、CDC)

    • 存储(Hive、Hbase、mysql、Kafka、数据湖)

    • 加工(Hive、Spark、Flink)

    • OLAP查询(Kylin、Clickhous、ES、Dorisdb)等。



2.2 稳定的离线数仓

早期规划中,在数据实时性要求不高的前提下,基本一开始都会选择建设离线数仓。

1) 技术实现



  • 使用Hive作为数据存储、计算技术栈

  • 编写数据同步脚本,抽取数据到Hive的ODS层中

  • 在Hive中完成dwd清洗加工、维度建模和dws汇总、主题建模

  • 依赖调度工具(dophinScheduler)自动 T+1调度

  • olap引擎查询分析、报表展示

2) 优缺点



  • 配合调度工具,能够自动化实现T+1的数据采集、加工等全流程处理。技术栈简单易操作

  • Hive存储性能高、适合交互式查询

  • 计算速度受Hive自身限制,可能因参数和数据分布等差异造成不同程度的数据延迟

3) 改良

既然我们知道了Hive的运算速度比较慢,但是又不想放弃其高效的存储和查询功能。

那我们试试换一种计算引擎: Spark。

整体流程不变,主要是在ods->dwd->dws层的数据加工由Spark负责。效果是显而易见的,比Hive计算快了不少。

目前两种离线数仓均完美的实现了业务需求。领导第二天一看报表统计,结果皆大欢喜~

现在考虑换一种场景:不想等到第二天才能看到结果,要求实时展示指标,此时需要建设实时数仓。


3 冗余 OR 回溯 ?

既然要求达到实时效果,首先考虑优化加工计算过程。因此需要替换Spark,使用Flink计算引擎。

在技术实现方面,业内常用的实时数仓架构分为两种:Lambda架构和Kappa架构。


3.1 Lambda架构

顾名思义,Lambda架构保留实时、离线两条处理流程,即最终会同时构建实时数仓和离线数仓。

1) 技术实现



  • 使用Flink和Kafka、Hive为主要技术栈

  • 实时技术流程。通过实时采集程序同步数据到Kafka消息队列

  • Flink实时读取Kafka数据,回写到kafka ods贴源层topic

  • Flink实时读取Kafka的ods层数据,进行实时清洗和加工,结果写入到kafka dwd明细层topic

  • 同样的步骤,Flink读取dwd层数据写入到kafka dws汇总层topic

  • 离线技术流程和前面章节一致

  • 实时olap引擎查询分析、报表展示

2) 优缺点



  • 两套技术流程,全面保障实时性和历史数据完整性

  • 同时维护两套技术架构,维护成本高,技术难度大

  • 相同数据源处理两次且存储两次,产生大量数据冗余和操作重复

  • 容易产生数据不一致问题

3) 改良

针对相同数据源被处理两次这个点,对上面的Lambda架构进行改良。

通过将实时技术流的每一层计算结果定时刷新到离线数仓中,数据源读取唯一。大幅减少了数据的重复计算,加快了程序运行时间。


3.2 Kappa架构

为了解决上述模式下数据的冗余存储和计算的问题,同时降低技术架构复杂度,这里介绍另外一种模式: Kappa架构。

1) 技术实现



  • 使用Flink和Kafka为主要技术栈

  • 实时技术流和Lambda架构保持一致

  • 不再进行离线数仓构建

  • 实时olap引擎查询分析、报表展示

2) 优缺点



  • 单一实时数仓,强实时性,程序性能高

  • 维护成本和技术栈复杂度远远低于Lambda架构

  • 源头数据仅作为实时数据流被计算、存储,数据仅被处理一次。

  • 数据回溯难。依赖Kafka存储,历史数据会丢失

  • olap查询难。Kafka需要引入其他对接工具实现olap查询,Kafka天生不适合olap分析。

总体而言,第一种Lambda架构虽然有诸多缺点,但是具备程序稳健性和数据完整性,因此在企业中用的会比较多。

相反Kappa架构用的比较少。因为Kappa架构仅使用Kafka作为存储组件,需要同时满足数据完整性和实时读写,这明显很难做到。

Kappa架构的实时数仓道路将何去何从?


4 新一代实时数仓

我们明白,Kafka的定位是消息队列,可作为热点数据的缓存介质,对于数据查询和存储其实并不适合。


4.1 数据湖技术

近些年,随着数据湖技术的兴起,仿佛看到了一丝希望。

目前市场上最流行的数据湖为三种: Delta、Apache Hudi和Apache Iceberg。

其中Delta和Apache Hudi对于多数计算引擎的支持度不够,特别是Delta完全是由Spark衍生而来,不支持Flink。

对于Iceberg,Flink是完全实现了对接机制。看看其具备的功能:



  • 基于快照读写分离和回溯

  • 流批统一的写入和读取

  • 非强制绑定计算引擎

  • 支持ACID语义

  • 支持表、分区的变更特性


4.2 kappa架构升级

因此考虑对Kappa架构进行升级,使用Flink + Iceberg技术架构,可以解决Kappa架构中的一些问题。



  • 存储介质由Kafka换成Iceberg,其余技术栈保持不变

  • Flink读取源头Kafka数据,结果存储到Iceberg ods层

  • 继续执行后续的ods->dwd->dws层计算、结果存储

  • Iceberg支持流批一体查询,过程中支持olap查询

  • 实时olap引擎查询分析、报表展示

目前Flink社区关于Iceberg的建设已经逐渐成熟,其中很多大厂开始基于Flink + Iceberg打造企业级实时数仓。

有兴趣的小伙伴欢迎添加我的个人微信: youlong525一起讨论~

》》》更多好文,欢迎关注公众号: 大数据兵工厂


推荐阅读
  • 在Linux系统中,原本已安装了多个版本的Python 2,并且还安装了Anaconda,其中包含了Python 3。本文详细介绍了如何通过配置环境变量,使系统默认使用指定版本的Python,以便在不同版本之间轻松切换。此外,文章还提供了具体的实践步骤和注意事项,帮助用户高效地管理和使用不同版本的Python环境。 ... [详细]
  • 技术日志:深入探讨Spark Streaming与Spark SQL的融合应用
    技术日志:深入探讨Spark Streaming与Spark SQL的融合应用 ... [详细]
  • 流处理中的计数挑战与解决方案
    本文探讨了在流处理中进行计数的各种技术和挑战,并基于作者在2016年圣何塞举行的Hadoop World大会上的演讲进行了深入分析。文章不仅介绍了传统批处理和Lambda架构的局限性,还详细探讨了流处理架构的优势及其在现代大数据应用中的重要作用。 ... [详细]
  • 从0到1搭建大数据平台
    从0到1搭建大数据平台 ... [详细]
  • 第二章:Kafka基础入门与核心概念解析
    本章节主要介绍了Kafka的基本概念及其核心特性。Kafka是一种分布式消息发布和订阅系统,以其卓越的性能和高吞吐量而著称。最初,Kafka被设计用于LinkedIn的活动流和运营数据处理,旨在高效地管理和传输大规模的数据流。这些数据主要包括用户活动记录、系统日志和其他实时信息。通过深入解析Kafka的设计原理和应用场景,读者将能够更好地理解其在现代大数据架构中的重要地位。 ... [详细]
  • FileBeat + Flume + Kafka + HDFS + Neo4j + SparkStreaming + MySQL:【案例】三度关系推荐V1.0版本11:每周一计算最近一月主播视频评级
    一、数据计算步骤汇总下面我们通过文字梳理一下具体的数据计算步骤。第一步:历史粉丝关注数据初始化第二步:实时维护粉丝关注数据第三步:每天定 ... [详细]
  • 本文探讨了在Windows系统中运行Apache服务器时频繁出现崩溃的问题,并提供了多种可能的解决方案和建议。错误日志显示多个子进程因达到最大请求限制而退出。 ... [详细]
  • Spark与HBase结合处理大规模流量数据结构设计
    本文将详细介绍如何利用Spark和HBase进行大规模流量数据的分析与处理,包括数据结构的设计和优化方法。 ... [详细]
  • Spark中使用map或flatMap将DataSet[A]转换为DataSet[B]时Schema变为Binary的问题及解决方案
    本文探讨了在使用Spark的map或flatMap算子将一个数据集转换为另一个数据集时,遇到的Schema变为Binary的问题,并提供了详细的解决方案。 ... [详细]
  • 本文探讨了 Kafka 集群的高效部署与优化策略。首先介绍了 Kafka 的下载与安装步骤,包括从官方网站获取最新版本的压缩包并进行解压。随后详细讨论了集群配置的最佳实践,涵盖节点选择、网络优化和性能调优等方面,旨在提升系统的稳定性和处理能力。此外,还提供了常见的故障排查方法和监控方案,帮助运维人员更好地管理和维护 Kafka 集群。 ... [详细]
  • HBase在金融大数据迁移中的应用与挑战
    随着最后一台设备的下线,标志着超过10PB的HBase数据迁移项目顺利完成。目前,新的集群已在新机房稳定运行超过两个月,监控数据显示,新集群的查询响应时间显著降低,系统稳定性大幅提升。此外,数据消费的波动也变得更加平滑,整体性能得到了显著优化。 ... [详细]
  • 在使用sbt构建项目时,遇到了“对象apache不是org软件包的成员”的错误。本文详细分析了该问题的原因,并提供了有效的解决方案,包括检查依赖配置、清理缓存和更新sbt插件等步骤,帮助开发者快速解决问题。 ... [详细]
  • NoSQL数据库,即非关系型数据库,有时也被称作Not Only SQL,是一种区别于传统关系型数据库的管理系统。这类数据库设计用于处理大规模、高并发的数据存储与查询需求,特别适用于需要快速读写大量非结构化或半结构化数据的应用场景。NoSQL数据库通过牺牲部分一致性来换取更高的可扩展性和性能,支持分布式部署,能够有效应对互联网时代的海量数据挑战。 ... [详细]
  • 深入解析队列机制及其广泛的应用场景
    本文深入探讨了队列机制的核心原理及其在多种应用场景中的广泛应用。首先,文章详细解析了队列的基本概念、操作方法及其时间复杂度。接着,通过具体实例,阐述了队列在操作系统任务调度、网络通信、事件处理等领域的实际应用。此外,文章还对比了队列与其他常见数据结构(如栈、数组和链表)的优缺点,帮助读者更好地理解和选择合适的数据结构。最后,通过具体的编程示例,进一步巩固了对队列机制的理解和应用。 ... [详细]
  • Phoenix 使用体验分享与深度解析
    闲来无事看了下hbase方面的东西,发现还好理解不过不大习惯于是找到个phoenix感觉不错性能指标如下好像还不错了准备工作:启动hadoop集群启动zookkeeper启动hba ... [详细]
author-avatar
央央说去_531
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有